IBIS Macromodel Task Group

Meeting date: 15 October 2019

Members (asterisk for those attending):
ANSYS:                        Dan Dvorscak
                            * Curtis Clark
Cadence Design Systems:     * Ambrish Varma
                              Ken Willis
                              Kumar Keshavan
Intel:                      * Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                              Radek Biernacki
                              Ming Yan
                            * Todd Bermensolo
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
SiSoft (Mathworks):         * Walter Katz
                            * Mike LaBonte
SPISim:                     * Wei-hsing Huang
Teraspeed Labs:             * Bob Ross

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None

-------------
Review of ARs:

- Ambrish to look into adding graphic or improved example to BIRD197.5.
  - Done.
  
- Randy to add "post-process" versus "post process" to the IBIS 7.0 known
  issues document.
  - Done.

- Walter to send the modified BIRD198 syntax proposal to Bob, Randy, Arpad
  and Mike L.
  - Done.

- Randy and Michael M. to invite DDR memory and controller vendors to comment
  on new protocols.
  - In progress.
  
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the October 8
meeting.  Mike L. moved to approve the minutes.  Walter seconded the motion.
There were no objections.

-------------
New Discussion:

BIRD198.1:
Walter noted that some email discussions had occurred amongst the private group
since the last meeting.  He asked what the dominant characteristic of a PDN
model is and said that he thought it was the capacitance between the power and
ground planes.  He noted that this is largely a function of the overlapping area
of the planes and the thicknesses and strengths of the dielectrics between the
various layers.  The capacitance is a function of what's in between the rail
planes.  The important question is whether there is any correlation between the
strength/speed of active transistors and the thicknesses and dielectric
constants of all the IC fab layers between the conductive planes for the rails.
Walter presented two examples, one of which could be used if there were a
correlation, and one of which could be used if there weren't.

Example 1 contained a PDN Group with process corners (typ/slow/fast).  It
contained a model between Vdd and Vss.  Walter noted that multiple models could
be provided between different rails, but this example focused on a single
model within the Group.  Values were provided for C_pdn, R_pdn, and R_leak, and
these were correlated with the typ/slow/fast I/V curves, so three columns were
provided for each value.  This is what could be used if the PDN characteristics,
largely capacitance, were correlated with the transistor process.

Example 2 contained multiple PDN Groups.  One was named "Large Cap" and another
was name "Small Cap", and there could be many more.  The groups themselves
could serve as the "corner" cases of the on-die PDN.  In this case the model(s)
within the groups would provide single values for C_pdn, R_pdn, and R_leak.  The
model maker could provide as many of these "corner" groups as they wanted.

The EDA tool could simply allow the selection of one of the groups, and if it
were like Example 1 values would then be selected according to process corner.
If it were like Example 2, then the single values would be specified directly.
Walter also noted that an EDA tool might provide a "No PDN Group" option in its
PDN model selection mechanism.  This would allow a user who had a BIRD189
Interconnect model that already contained all the on-die PDN modeling to skip
using the PDN Groups altogether.

Arpad noted that Example 1 contained 3 columns of values for the parameters
according to process corner (typ/slow/fast).  He therefore preferred that the
Subparam names be C_pdn_corner, R_pdn_corner, and R_leak_corner similar to the
[C Comp Corner] keyword.  Walter noted that [C Comp] and [C Comp Corner] are
keywords, and these _pdn values are Subparams.  Arpad acknowledged the
difference but still felt it would be much clearer if _corner were used for the
PDN parameter names in the correlated (typ/slow/fast) case.  Walter agreed and
changed the Subparam names in Example 1 to add the _corner suffix.

Walter noted that he thought Randy was ready to prepare a response to the
authors based on these examples.  Randy agreed and noted that the authors are
presenting this proposal at the upcoming IBIS Summit in Tokyo, so we want to get
them feedback in time for their presentation.

Randy noted some of his feedback from the private email discussions.  He said
that choosing the PDN corner that's going to create best/worst case conditions
is complicated.  The PDN capacitance is interacting with PDN inductance in the
package, and you can get some resonance between those.  Depending on the data
rate of the signals involved, that resonance could be an issue.  So one may have
to analyze all sorts of combinations to figure out a best or worst case PDN.
Arpad asked if the second example with multiple "corners" would be the way to
handle that scenario.  Randy agreed, since this wouldn't really be correlated
with a process corner, and someone may want to make different selections.

Walter said he would send the modified proposal and example to the private email
list so Randy could prepare a response to the authors of BIRD198.  Randy agreed.

DC_Offset BIRD:
Ambrish shared a modified version of the BIRD197.5-3 draft he had emailed the
ATM list prior to the meeting.  He noted that Walter and Fangyi had pointed out
confusion that could arise based on his initial version, and he acknowledged
that this was true because of cut-and-paste errors introduced while creating
the examples from older versions of the draft.

Ambrish noted that the example Application Scenarios he had introduced now
explicitly explain the ranges of the post-processed waveforms.  He noted that
the two examples essentially illustrate the same thing, and we could remove one
if people felt they were redundant.  Fangyi suggested that the statements about
post-processed waveform ranges be moved to the end of bullet c (i.e., the end
of the explained flow) in both examples.  Ambrish agreed that this was much
clearer and made the change.  Walter agreed.  Fangyi noted that this version
addressed all the questions he'd raised about the original version.

Walter noted that there were still some open issues.  He noted two sentences
that had been added to the end of the Usage Rules:

   The Rx AMI_GetWave output waveform returned by the AMI model must be
   nominally centered around zero Volts.

and:
 
    The High/Low Threshold of [the] Rx AMI_GetWave output waveform returned by
    the AMI model shall be zero Volts.

Walter said he preferred the second sentence.  Ambrish said that he preferred
the first one and that if they're equivalent, he prefers the first sentence
because it's simpler.  Walter said he was okay deleting the second sentence and
keeping the first, as long as it's on the record that they are considered
equivalent.

Randy, Fangyi, and Arpad suggested other editorial corrections, and Ambrish
updated the document.  Arpad asked if this version could be summarized in the
following way:
   DC_Offset is an In parameter, and NRZ_Threshold has been removed.

Ambrish agreed, and Randy noted that this version was simple.

Ambrish moved to submit the modified version to the Open Forum as BIRD197.5.
Walter seconded.  There were no objections.  Ambrish agreed to send the proposal
to Randy, and Randy agreed to notify the Open Forum and officially post the
BIRD.

Enabling Back-channel in Statistical Mode:
Walter reviewed his first draft of a BCI Statistical Training BIRD.  He noted
that he thought people had preferred to iterate with AMI_Init() rather than add
a new AMI_Impulse() function.  Arpad said he wasn't sure anyone had expressed
a real preference yet.  Mike L. had suggested a way we might iterate with
AMI_Init(), and Radek had agreed with Mike's suggestion.  Walter said the
proposal could easily be modified if we decided to go with a new AMI_Impulse()
function instead.

Walter reviewed the proposed spec changes:
- New BCI_Training_Mode reserved parameter.
  - Allowed values of "Init", "GetWave" or "Dual"
- Iterate with AMI_Init().
  - Value pointed to by AMI_memory_handle indicates whether this is the 
    initial call to AMI_Init() or not.
- Flow keeps iterating between calls to Tx and Rx AMI_Init() until the
  value of BCI_State returned by the Rx AMI_Init() is "Converged".
- Flow for repeaters has not been fully addressed yet (will be added).

Arpad asked what the functional reason for adding an AMI_Impulse() would be.
Walter said we could do everything by iterating with the existing AMI_Init().
If we did that, the contents of AMI_memory_handle would be null the first time
AMI_Init() was called and would contain the value returned by the model on
subsequent calls.  As long as we accept that newly added purpose for
AMI_memory_handle, everything can be done by iterating AMI_Init().  Walter
noted, however, that previous proposals to overload existing function arguments
had been rejected.  He noted, for example, that a proposal to pass parameter
values into AMI_GetWave() using the ami_parameters_out argument had not been
well received.

Michael M. asked if this was part of an historical correction in that AMI_Init()
was originally designed only for set-up and initialization, and IR processing
for statistical flow had been added later.  Walter said this was not true.  He
noted that AMI_Init() had always been expected to work with the channel IR.  He
noted that the Tx AMI_Init() had taken an IR for the channel so the Tx could
optimize itself for performance at the Rx pad.  Statistical analysis and
processing had always been part of AMI_Init().

Arpad noted that earlier discussions on improving the Redriver Init Flow had
also considered the possibility of calling AMI_Init() multiple times.  He asked
if this might be a good time to consider separating signal processing from
AMI_Init() and leaving AMI_Init() to focus purely on set-up and initialization.
Ambrish asked if, instead of overloading AMI_Init(), we could instead override
AMI_GetWave() and introduce a switch that lets the EDA tool iterate
AMI_GetWave() with IRs instead of waveforms.  He noted that the flow being
introduced here for iterating AMI_Init() was identical to the AMI_GetWave()
training flow that already existed.  Walter agreed the flows were similar, but
he asked Ambrish how you would tell AMI_GetWave() that you were passing it IRs
instead of waveforms.  Arpad said that in the past many members seemed to have
preferred adding new functions instead of overloading existing ones, even if
there was a certain amount of overlap.

Walter said he would clean up the draft, add more to the repeater flow, and send
it to the ATM list again.  He noted that the fundamental question is still what
function we will use to iterate in statistical training mode.

- Michael M.: Motion to adjourn.
- Randy: Second.
- Arpad: Thank you all for joining.

AR: Walter to send the latest BIRD198 syntax and examples proposal to Bob,
    Randy, Arpad, and Mike L.
AR: Randy to draft a new response to the BIRD198 authors.
AR: Ambrish to send the BIRD197.5 proposal to Randy.
AR: Randy to notify the Open Forum and post BIRD197.5.
AR: Walter to send out draft 2 of the BCI for Statistical BIRD.

-------------
Next meeting: 22 October 2019 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
